Graphical user interfaces have become standard fare on most computers sold today. For example, versions of the MICROSOFT WINDOWS operating system provide a graphical user interface in which a pointer is positionable over windows on a screen via an input device such as a mouse or a trackball. Clicking a button on the input device when the pointer is positioned over a given feature of the window, such as a control, registers with the program hosting the window, such that the program performs a given functionality associated with the control. For example, moving the pointer over a “save” button in a window hosted by a word processing program, and clicking a button on the input device, typically causes the word processing program to save the current file to a storage device (such as a hard disk drive).
While graphical user interfaces may offer computer users great advantages in ease of use and productivity as compared to traditional text-only user interfaces, they make program development more difficult for computer programmers. A computer programmer, for example, must not only be concerned with programming the given functionality of a computer program, but also with providing for windows, and controls within those windows, so that users can access the functionality. Typically, this means that the programmer must be well-versed in writing programs that operate within a given operating system, such as versions of MICROSOFT WINDOWS operating systems. Using the WIN32 application programming interface (API), for example, the programmer is able to have an application program host windows, and host rudimentary controls within those windows (e.g., dialog boxes, check boxes, buttons, text-entry fields, etc.).
A programmer does not have a vast number of different controls with the WIN32 API, however, to utilize when developing a computer program. The programmer is then usually left with having to create user interface controls himself or herself for inclusion into the computer program. Development of user interface controls, however, is a tedious and time-consuming endeavor. Furthermore, many programmers that may be skilled in other areas of program development (e.g., such as a database expert), may not be similarly skilled in developing user interface controls.
Various technologies have been developed in an attempt to remedy this potential problem. ACTIVEX controls are currently being utilized with desktop-oriented application programs in the MICROSOFT WINDOWS operating system. ACTIVEX controls are known within the art, and are described in Adam Denning, ActiveX Controls Inside Out (ISBN 1-57231-350-1) (1997), and David Chappell, Understanding ActiveX and OLE (ISBN 1-57231-216-5) (1996), both of which are hereby incorporated by reference. For example, in the Chappell book, on page 205, is states that qualifying as an ActiveX control (OLE Controls technology was renamed ActiveX Controls) requires only support for the IUnknown interface and the ability to self-register with the system registry. Using ACTIVEX controls that have already been created means that computer programmers do not have to “reinvent the wheel”—that is, they do not have to create controls that have been already created by others.
However, for many programmers normally accustomed to only the WIN32 API, using ACTIVEX controls in MICROSOFT WINDOWS operating system-intended programs is not straightforward. A programmer may, for example, have to write original “container code,” so that the ACTIVEX control may be hosted within a window via the container code. Again, many programmers may not be experienced in creation of such container code. Furthermore, hosting ACTIVEX controls within application program windows may require the programmer to have experience in Component Object Model (COM) objects, which the programmer may not have. COM is known within the art, and is described in Dale Rogerson, Inside COM (ISBN 1-57231-349-8) (1997), which is hereby incorporated by reference. Thus, even if having access to a large number of ACTIVEX controls, a programmer may still not be able to easily include them in a given computer program under development.
A limited solution to this problem is provided by the Microsoft Foundation Classes (MFC). ACTIVEX controls may be accessible through MFC for programmers who use the computer language C++ to develop computer programs. a significant disadvantage is presented to those programmers who do not utilize C++ to develop programs. That is, because MFC is typically not accessible except through C++, a computer programmer without such knowledge may find himself or herself still unable to utilize existing ACTIVEX user interface controls within computer programs the Again, however, programmer may be developing.
There is a need, therefore, for permitting computer programmers to include ACTIVEX controls in their programs in an easy-to-understand and straightforward fashion. That is, there is a need for permitting computer programmers to include ACTIVEX controls in their programs without having to resort to COM, or MFC (via C++). Ideally, a programmer should be able to include ACTIVEX controls in a computer program using precepts and constructs already familiar to him or her.